大家好，我是 ShenDesk 的作者。多年來我一直致力於開發這款安全、穩定、可靠，且輕量級、可私有化部署的客服系統。這幾年下來，陸續累積了不少使用者。對一名工程師來說，能看到自己的產品被客戶投入正式生產環境商用，既讓我感到欣慰，也是我動力的來源。

時間來到 2026 年，今年對我來說或許會是轉折的一年。經過前幾年的努力與試錯，特別是去年將近一年的衝刺（可以參考我官網上的更新日誌，去年的更新量超過了前幾年的總和），我現在有足夠的信心說，這款產品已經達到了高可用性、企業級的技術水準。在這個過程中，我要特別感謝一些使用者的信任與支持（無論是精神上或實質上的支持，由衷感謝各位）。

在 2026 年，我給自己立下了一個新目標：透過一系列文章來介紹並回顧開發這款客服系統的過程。一方面是讓自己從疲憊的寫程式工作中抽離，回到社群，重新磨練自己的寫作與溝通技能；另一方面，我希望透過分享與交流，能找到志同道合的朋友。

在這一系列的文章中，我不會使用 AI 來協助寫作，也不會長篇大論地介紹基礎知識。我會將重心放在自己遇到的問題以及面對這些問題時的思考，說明自己在面對挑戰時如何權衡與取捨，進而達成關鍵目標（開發出一款安全、穩定、可靠、輕量化且可私有化部署的客服系統）。因此，這些文章的篇幅可能不長，文筆或許也稱不上華美，還請各位見諒。

如果您對我的這款產品感興趣，歡迎到我的網站看看：https://shendesk.com 。

在本篇中，我將介紹為客服系統開發 AI 智慧客服時，對於「知識庫」這項核心功能的架構選型與思考過程，以及具體如何實現。

引言

在 AI 浪潮的席捲下，沒有任何一款客服軟體能夠忽視它。為客服系統增加 AI 客服功能已不再是加分項，而是必備功能。要讓客服系統具備 AI 客服的能力，通常有以下幾種方式：

1. 完全使用 AI 平台的雲端服務： 將使用者的知識庫上傳到 AI 平台，當訪客在對話視窗提問時，直接調用 AI 平台的 API 來實現智慧客服功能。
2. 搭建私有化 AI 平台（如 Dify）： 透過 API 介接的方式，讓客服系統與其互通。

   Dify 是一個開源的大語言模型（LLM）應用開發平台，旨在簡化並加速生成式 AI 應用的創建與部署。它為開發者提供了友善的使用者介面與一系列強大工具，使其能快速搭建生產級的 AI 應用。

3. 完全內建 AI 能力： 自行實現知識庫的向量化與檢索（RAG），並內建直接調用開源模型的能力。

針對第一個選項（完全使用雲端服務），雖然方案最輕量、最容易實現，但這與「100% 私有化部署、數據 100% 自主掌控（保存在地端）」的原則相衝突。對於政府、金融、保險等對數據敏感的客戶來說，這是無法接受的。

第二個選項（搭建 Dify），對於大量的小規模團隊而言則「太重」了。小企業通常沒有專門的 IT 專家，要部署並維護一套如此複雜的系統，門檻實在太高，且通常需要配備 GPU 的伺服器進行模型推理。

第三個選項（完全內建 AI 能力），除了開發成本巨大外，同樣會大幅增加小規模團隊的部署難度。這需要額外部署資料庫組件來支援向量檢索，同樣也需要高效能硬體支援，門檻依然過高。

我的現狀與目標

回到我最初的目標：開發一款安全、穩定、可靠、輕量級且可私有化部署的客服系統。

我特別標註了「輕量級」這一點。在過去幾年的開發過程中，我接觸到大量的小團隊，有的甚至只有幾個人、甚至只有一個老闆。他們可能只是想在現有的企業官網或 App 中加入簡單的客服功能，以便與潛在客戶進行基本溝通、把握訂單。當他們看到複雜的系統說明與術語時，往往會直接被勸退。他們需要的，就是簡單、簡單、足夠簡單。

特別是這類小團隊在進行私有化部署時，往往無法承擔高昂的伺服器與頻寬成本。我曾遇過不少用戶直接在現有的 Web 伺服器上加裝客服系統，或者趁雲端服務商促銷時，買一台特價的 2vCPU / 4GB 記憶體主機來部署。這類用戶佔了絕大多數（但這不代表他們對系統的穩定性與安全性有所妥協）。

因此，前面提到的方案 2 與方案 3 基本可以排除，除非我打算放棄這群廣大的小規模用戶，但這顯然不可能。

看起來剩下的唯一選擇是方案 1：完全使用 AI 平台雲端服務。

然而，AI 客服的功能不僅僅是調用模型聊天，核心需求是讓 AI 根據「使用者自己的知識庫」與訪客交流（例如：「如何下單？」、「訂單幾天送達？」）。

這中間需要「知識庫」作為橋梁。如果完全依賴雲端平台，勢必要求用戶將所有知識庫文件上傳到公有雲，這對許多重視資安的用戶（特別是政府、金融、保險領域）來說又是死穴——數據上雲等於直接出局。

所以，這裡產生了另一個前提條件：知識庫必須 100% 儲存在使用者的在地端資料庫。

一個最可行的折衷方案是：當訪客使用 AI 客服功能時，系統先檢索「在地端資料庫」中的知識庫內容，接著構建提示詞（Prompt），再調用 AI 平台的能力。這與方案 1 的不同之處在於，我會直接介接 Gemini、GPT，而不是將知識庫託管在協力廠商的平台上。

管理在地端知識庫

那麼這個方案的核心就在於：如何構建並管理在地端知識庫。

透過向量資料庫（Vector Database）管理固然是最佳選擇，但我在前文中提到了一個制約條件：私有化部署必須足夠輕量，不能增加使用者的部署負擔。

此時，我的方案已初步構思為：在地端資料庫 + 全文檢索（Full-text Search）+ 召回（Recall）Top N + 構建提示詞（Prompt）。

全文檢索的成熟方案很多：

1. Elasticsearch： 行業的事實標準，分散式架構，原生支援大規模叢集、分片與副本。
2. OpenSearch： AWS 因為不滿 Elastic 公司的協議變更，從 Elasticsearch 分支出的開源版本。
3. Solr： 老字號選擇，在精準分詞、傳統文字檢索上仍具優勢，但分散式擴展性遜於 ES。除非是維護舊專案，現在新專案極少將其作為首選。
4. 其他： Meilisearch（Rust 編寫）、Typesense（C++ 編寫）...

回想以前在公司參與專案時，基本上都是直接上 Elasticsearch。那時參與的專案通常有大客戶支撐、幾百萬的合約，並擁有非常寬裕的伺服器環境與成熟的運維團隊。

但現在，這些我通通都沒有。我要服務的小規模團隊，完全無法在私有化部署時搞一個像 Elasticsearch 這樣的「重裝武器」。

那該如何解決這個困境？再次回到我的現狀：我的大部分使用者都是小團隊，對於 AI 知識庫的管理來說，有一個顯著的特點，就是知識庫的規模通常較小。如果你跟他們說你的方案能在毫秒間檢索數萬篇、幾十 GB 的文件，他們會覺得這跟他們的需求根本不在同一個頻道。

小規模團隊的知識庫文件數量通常只有數十篇，達到數百篇的已經很少見了。總結一下目前的條件與需求：

1. 數據必須 100% 在地化： 採用「在地端資料庫 + 全文檢索 + 召回 Top N + 構建提示詞」方案，將提示詞發送到 AI 模型（如 Gemini、GPT）。
2. 必須輕量級： 不能增加任何私有化部署的負擔。能實現數百篇知識庫文件的檢索已綽綽有餘。

最終，只剩下一個成熟的選擇：Lucene。

它無需安裝部署任何獨立服務，零依賴，可以直接整合進服務端主程式中，使用者在進行私有化部署時完全無感知。

實際上，Lucene 並不弱。對於 100 萬至 1000 萬篇文件的規模，查詢延遲通常僅在 10-50ms。用來服務小規模使用者的數十篇、數百篇文件，簡直是輕輕鬆鬆，毫不費力。

結語

關於 Lucene 該如何使用，網路上的優秀文章已經太多太多，我並不打算在這邊班門弄斧。

正如我在開篇中所說的，我會在這一系列文章中，將精力放在自己遇到的問題以及面對這些問題時的思考，說明自己在面對挑戰時如何權衡與取捨，進而達成關鍵目標（開發出一款安全、穩定、可靠、輕量化且可私有化部署的客服系統）。

我希望這一系列文章，更像是記錄一個獨立開發者的心路歷程。謝謝您的關注與支持 :)